home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.20021006-20030409 / 000182_huang@monair.com_Thu Dec 12 14:10:27 EST 2002.msg < prev    next >
Text File  |  2020-01-01  |  4KB  |  93 lines
  1. Article: 13963 of comp.protocols.kermit.misc
  2. Path: newsmaster.cc.columbia.edu!panix!newsfeed.mathworks.com!cyclone.swbell.net!newsfeed1.easynews.com!easynews.com!easynews!feed.news.qwest.net!news.uswest.net.POSTED!not-for-mail
  3. From: "Frank Huang" <huang@monair.com>
  4. Newsgroups: comp.protocols.kermit.misc
  5. References: <suMJ9.34$CC2.77960@news.uswest.net> <at8649$2qj$1@watsol.cc.columbia.edu>
  6. Subject: Re: remote dir
  7. Lines: 74
  8. X-Priority: 3
  9. X-MSMail-Priority: Normal
  10. X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
  11. X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
  12. Message-ID: <A15K9.159$hM2.68422@news.uswest.net>
  13. Date: Thu, 12 Dec 2002 14:00:47 -0500
  14. NNTP-Posting-Host: 208.44.244.66
  15. X-Trace: news.uswest.net 1039719648 208.44.244.66 (Thu, 12 Dec 2002 13:00:48 CST)
  16. NNTP-Posting-Date: Thu, 12 Dec 2002 13:00:48 CST
  17. Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:13963
  18.  
  19. Frank:
  20.     Thanks for your help.
  21.  
  22.             Frank Huang
  23.  
  24. "Frank da Cruz" <fdc@columbia.edu> wrote in message
  25. news:at8649$2qj$1@watsol.cc.columbia.edu...
  26. > In article <suMJ9.34$CC2.77960@news.uswest.net>,
  27. > Frank Huang <huang@monair.com> wrote:
  28. > : Hi Everyone:
  29. > :     I am using TurboPower Async ActiveX.
  30. > :     On the client, I sent a 'G' packet with 'D' as the Data field.
  31. > :     Then on 3.15 Server, it tries to send $KERMIT$.TMP over, but when I
  32. > : tries to receive the file, it logs
  33. > :     the following messages.
  34. > :     On the server and client, I have the Block-check-type set to be CRC
  35. > :     If I sent a 'G' packet with 'FINISH' or 'LOGOUT' as the Data field,
  36. then
  37. > :     it works find.
  38. > :
  39. > We don't provide a debugging service for competitors who sell unlicensed
  40. > implementations of our protocol.  MS-DOS Kermit 3.15 includes a correct
  41. > implementation that can be used on DOS and on Windows 3.x.  MS-DOS Kermit
  42. > is not supported on 32-bit Windows, which has its own Kermit software,
  43. > Kermit 95:
  44. >
  45. >   http://www.columbia.edu/kermit/k95.html
  46. >
  47. > But that's not the problem in this case.
  48. >
  49. > Your log shows:
  50. >
  51. > : Rpack: ^A, GD READ.ME6^M
  52. > : Spack: ^A5 S~( @-#Y3~^?5% ___E#^M
  53. > : Rpack: ^A0 Yp% @-#Y3~ !  Z^M
  54. > : Spack: ^A)!Xdir !R>^M
  55. > : Rpack: ^A# N&0
  56. > : <Bad checksum>
  57. > :
  58. > MS-DOS Kermit sent a correct X packet with the three-byte block check
  59. (CRC)
  60. > that was successfully negotiated.  The other Kermit could not read it and
  61. > sent a NAK.  Furthermore the NAK itself is malformed (it claims to have a
  62. > 1-byte checksum, but in fact has a two byte one; even if you ignore the
  63. > spurious second byte, the first one is wrong):
  64. >
  65. > : Spack: ^A'!Xdir "^M
  66. > : Rpack: 6^M^A# N&0
  67. > : <Bad checksum>
  68. > :
  69. > Since it keeps happening, it's not because of transmission errors; it's
  70. > because the other Kermit program is totally broken.  Maybe it will work
  71. > better with 1-byte checksums.
  72. >
  73. > If you want to embed Kermit protocol in a Windows application you are
  74. > developing, perhaps you should come to us for it since we know the
  75. protocol
  76. > and actually go to some lengths to implement it correctly and efficiently.
  77. > See:
  78. >
  79. >   http://www.columbia.edu/kermit/k95faq.html#embedding
  80. >
  81. > and:
  82. >
  83. >   http://www.columbia.edu/kermit/ek.html
  84. >
  85. > Better still, companies that make products like the one you are trying to
  86. > use should come to us and license a supported implementation, instead of
  87. > torturing their customers as well as end-users (not to mention us and the
  88. > readers of this newsgroup) with broken and/or substandard implementations.
  89. >
  90. > - Frank
  91.  
  92.  
  93.